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they want na to agree with them— ”If OCS doesn't agree with u», 
they aren’t liatening, ” I can sapport this with evidence of OSD 
withdrawal to "we'll see" or other platitudea when wo get down to 
nuts and bolts. W« seem to get sacked into one of those games 
people play called 'Vos, bat.” Not withstanding these bleak realities, 
I don't think the situation is hopeless, hence I won’t stop her®. 

3. A simple way to eaipress our d ivisi on of reap oaaibilities 

{and like all attempts to simplify, this one has its pitfalls) is to say 
that, OSD ahould fill in technological gaps in OCS, users* service 
gape- Putting it another way* OHD should up npt wagra our 

available time leaves off, but where our ^owledge leaves off. 
Unfortunately, in our view they have not complemented our efforts 
in this fashion. Some believe it is because they don’t know how to 
extend the technology and at best they can try to keep up by lollowing 
In. our wake, but etriking out laterally, encroaching on our domain 
with a technique that Is interesting to our customers — which we 
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MEMORANDUM FOR THS RECOHD 

SUBJECT: . Miacellaneoua Notes on the OCS/ORD Relationship 
{Vintage, Spring 1968>'\, 



1. The same problems we had ia 1965 are still with us. I 
remain skeptical that more formal mechanisms will improve 
communications. While this Is cited as the basic problem by 
IPRD, it is only a manifestation of a deeper problem: "What do 
we have to talk about"? There is a fundamental barrier between 
us that is a function of the people involved on both sides, profes- 
sioisal jealousies and iateraats, and orgaaiaational responsibilities 
(in that order of significance, but the irony is that the degree we 
can do something to change this is probably the reverse order). 

2. ^ad others in IPRD express their frustration as a 
communications problem, but I think it boila down to the fact that 
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probably built, or coaaidere^a aud rejected, la tb« first place. Maybe 
our reaction is similar to that of the teacher ■who has mixed emotiona 
about Ms success with a student who then turns cocky. In summary, 

I think 'we can use the idea stated in the first sentence as a basic test. 

4. As I said before, another source of problems is the IPHD 

emphasis on mo’ving the project directly and smoothly into useful 
operation. The nature of H&D is such that this preoccupation can be 
destructive:: O ■ C v ^ 

■ ' j'. ™ "v " I" ' r • • s ■■ 

—It shifts the emphasis a'way from the problems that warrant 
. calling the project B&D in the first place. ' 

—It provides few opportunities to learn from mistakes. 

—It discourages experimentation or thoughtful evaluation of 
results.; ' ^ 

—It often forces GCS into an embarrassing position of not 
satisfying customer requests with the ease that OHD 
convinces them we should be able to do. ; v ^ 

When we suggest that their orientation may be wrong, they mention 
the directives to use live data and to have customer involvement* 
These two requirements do not necessarily imply operational goals, 
but how can they be convinced of this? In any event, there are easier, 
cheaper ways to get things going that are within the state-of-the-art— 
■without the insertion of a ponderous facade of pseudo R&D. 

5. Another point here is worth focdslng on; the implications 
of an operational goal seem to occur to ORD only after the project 
starts— long after the usual questions of ecotmmlc feasibility should 
be iraised. They must either give attention to these questiona earlier 
{as we normally do) or continue to ignore them and not be so intent 
on making the project go (the latter option being preferred). 

6. Another negative point; I believe that R&D people should ’stay 
out of the systems building area, that is, building something new from 
individual well-established techniques and facilities. Information 
systems building now is a crude art that is best practiced outside the 
RSfD area. By my definition then, building information systems, no 
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This, of course, may not be the case outside the information 
processing world. 'Whatt is needed is R&D in new or improved 
techniques, including a better systems a ralys is methodology. 

ORD’s reply to this would be ttiat they must have a system to test 
the techniques, but it seems that system building costs overshadow 
those related to technique development. You don’t need to design 
and boild a new car footn scratch to test a new steering wheel. 

^ ** How do you 

|[et bur^ people interested la helping debug or improve a mediocre, 
error-ridden operatiug system that they eav is ne eded to test an 
attractive idea? Why is it necessary for | ] s:o reinvent several 

programs and hardware packages to test the concept of an analTst'a 
“work station. “ ■■ ^ /■' , ’■ , o- 

7 . This loads to another point regarding hardware versus 
techniques in R3rD projects: which has the primary influence on 
the other at IPRD? Unfortunately, most of us think that hardware 
is the dominant factor. 2 concede that in many cases this must be, 
but only when hardware limitat i ons are to be considered- It is 
wrong to force the project to mushroom so that it fills every nook ' 
and cranny of the hardware s capability and then perhaps wonder 
3m application going is so expensive, 

:: ^ , 

I Dtjpucy director oi Computer Services 
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